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1 ELECTRONIC MAIL SOFTWARE WITH MODULAR INTEGRATED AUTHORING/READING 

2 SOFTWARE COMPONENTS INCLUDING METHODS AND APPARATUS FOR 

3 CONTROLLING THE INTERACTIVITY BETWEEN MAIL AUTHORS AND RECIPIENTS 

4 

5,>^ This application is a cpa€inuation-in-part of application 



0^ 




^ ^< ^ serial number 09/209, 1^2 filed December 10, 1998, and serial 



7 number --/ ,— -/filed , 2000 [BAK-006] the complete 

8 disclosure of/which is hereby incorporated by reference herein. 
9 

0 BACKGROUND OF THE INVENTION 



=S1 1 



nJ 2 1, Field of the Invention 



5 



1 3 The invention relates to an electronic mail program. More 



m1 4 particularly, the invention relates to an electronic mail program 

fij 

5 having modular integral authoring /reading applications whereby 



n 



:1 6 documents created with the modular integral authoring/ reading 

1 7 applications are seamlessly sent and received by the mail program 

1 8 and which provides different kinds of interactivity with and 

1 9 different kinds of access to electronic mail messages depending on 
2 0 user types or roles, 

21 

22 2, State of the Art 

23 In recent years electronic mail ("email") has become widely 

24 used in business, education, and in personal communications. One 
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1 of the features of electronic mail which is most convenient, 

2 particularly in business and in education, is the ability to 

3 attach a binary computer file to an email message. This feature 

4 enables email correspondents to rapidly share word processing 

5 documents, database documents, spreadsheet documents, multimedia 

6 documents f or virtually any kind of binary file created by a 

7 computer. There are, however, some serious limitations and 

8 inconveniences associated with attaching a binary file to an email 
":S 9 message, 

ko 

fli 1 The original Internet mail system as defined in 1982 with RFC 

W2 (Request for Comments) 821 and 822 had a number of important 

s 

013 limitations. In particular, the system was not designed to carry 

yi 

fill 4 large quantities of arbitrary data in an email message. In fact, 

si 

q1 5 the 1982 SMTP (Simple Mail Transport Protocol) standard required 

^ 6 that an email message consist of a single message containing only 

1 7 ASCII characters in lines of 1000 characters (blocks of 32k) or 

18 less. Moreover, some implementations of SMTP or other mail 

19 transport systems (such as UUCP) restricted message lengths to 

20 some allowed maximum number of bytes. Lengthy messages passing 
2 1 through a mail gateway using one of these implementations were 
22 likely to be truncated. 

23 
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1 The ability to send large quantities of binary data through 

2 the Internet electronic mail system was made possible with the 

3 MIME (Multipurpose Internet Mail Extensions) standard for Internet 

4 messages. The original MIME standard was published as an Internet 

5 Request For Comments docximent (RFC 1341) and approved in June of 

6 1992. (See Internet RFCs 2045,2046, and 2047 for the latest MIME 

7 standards documents,) The MIME standard describes how an email 

8 message should be formatted in order to be considered MIME 

^9 compliant. MIME defines a set of message header fields and a set. 

]Q 0 of message encoding standards that are designed to overcome the 

CI 1 limitations of RFC 822 message formats and still be transportable 

2 through any of the numerous legacy mail transport systems in use 

i y 

^3 on the Internet. MIME message header fields extend those defined 

0 4 in RFC 822 and describe the content and encoding type of the email 

i| 5 message. Encoding schemes allowed in the MIME standard include 

^6 ''quoted-printable", and "base64". In addition, three xinencoded 

H7 data types are allowed. These are labeled ''8bit", ''7bit", or 

1 8 ^'binary" . 

19 

20 If the sender and the receiver of the email message with the 

21 attached binary file are using the same brand and version of email 

22 program and both programs are configured in substantially the same 

23 way, the receiver's email program should automatically apply the 

24 appropriate decoding to the attached binary file and produce a 
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1 file which is identical to the file which was attached to the 

2 email by the sender. However, if the sender and receiver are 

3 using different email programs, the recipient may receive a file 

4 which must be decoded by the recipient using a separate decoding 

5 program . 
6 

7 Even after the file is properly received and decoded, it is 

8 often difficult for the receiver of the file to open the file. 
^^9 The receiver of the file might expect that "clicking" on the file 
yjO icon will open the file. However, clicking on the file icon will 
fll often not open the file. It may result in an error message like 
Jj2 "application not found" or, worse, it may result in the file being 
s1 3 opened by an inappropriate application thereby displaying 

y1 4 "gibberish". The receiver of the file must have a program capable 

ry 

5 of reading (opening) the file. For example, if one attaches a 

O 

^ 6 spreadsheet file to an email message, the receiver of the file 

17 must have a spreadsheet program in order to open the file. 

1 8 Technically, it is not necessary that the receiver of the file 

19 have the same brand program as that which created the file. 

20 However, opening a file with a program which did not create it, 

21 though possible, can be very inconvenient. The receiver of the 

22 file must know what kind of file is attached to the email message, 

23 must know what program on their computer is capable of reading 

24 that type of file, must launch the program, must open the file 
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V from within the program, and wait while the program translates the 

2 file. 
3 

4 The limitations of Internet electronic mail can become even 

5 more frustrating if the sender and recipient are not using the 

6 same operating system (OS) . Some mail attachment encoding schemes 

7 (and file compression schemes) are OS-dependent and it is possible 

8 that an email recipient could receive a file which is impossible 
[5 9 to decode (or decompress). 

|o 

1 These limitations in electronic mail have discouraged many 

^2 people, particularly non-sophisticated computer users, from 

^13 attaching files to electronic mail messages. In fact, for some 

ffd 4 novice users, the task of launching one application to create a 

\|1 5 document, saving the docxament, launching a separate email 

q1 6 application to create an email message, and then locating the 

1 7 saved document for attachment to an email message is daunting 

1 8 enough to discourage them. In addition, novice users often 

1 9 complain that after "downloading" a file attached to an email 

20 message they cannot find the file on their hard disk. 
21 

22 Another interesting aspect of electronic mail is that it is 

2 3 now widely used in electronic commerce, but only in a very limited 

24 way. Electronic mail is used by vendors to advertise goods and 
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1 such electronic mail may typically include a hyperlink which, if 

2 clicked on, will cause the mail recipient's computer to laianch a 

3 web browser and connect to the vendor's website where the goods 

4 may be purchased. Electronic mail is also used by online vendors 

5 to provide customer support by answering questions sent to the 

6 vendor via electronic mail and to confirm online purchases by 

7 sending electronic mail to the purchaser, 
8 

9 My previously incorporated parent application discloses 

ffl 

f4 0 electronic mail software which includes a main email component and 

21 a number of installable components. The installable components 

Ly 2 include authoring/ reading components for creating/ reading 

y 3 different kinds of documents and mailbox components for listing 

2!l 4 different kinds of messages or for listing messages in different 

'^15 styles. The main email component provides an underlying graphical 

Ol 6 user interface for functions directly associated with the storage 

17 and transfer of electronic mail messages, and also handles all 

1 8 data bundling and iinbundling required to transform a message 

19 created by an authoring component into a MIME compliant message. 

2 0 The authoring /reading components act like applications embedded 

21 within the email program and allow specific types of documents 

22 such as spreadsheets, graphics, databases, etc. to be created from 

23 within the email program and emailed directly. The 

24 authoring /reading components also allow received documents to be 
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1 read without the difficulties traditionally associated with 

2 attaching binary files to an email letter. The authoring 

3 components of the invention pass data to the main email component 

4 which packages the data as a MIME compliant message. When the 

5 message is received, the main email component concatenates (as 

6 needed) and decodes the MIME message and sends the data to the 

7 authoring /reading component associated with the MIME type. The 
O 8 electronic mail software also includes modular integrated 

yi 9 authoring /reading software wherein the functionality of the 

^0 authoring /reading software is controlled by the "role" of the user 

pj 1 when participating in an exchange of messages. One example of 

J12 "roles" given in the parent application was that of teacher and 

^3 student. Another example was that of a puzzle encoder and a 

tj5 4 puzzle decoder. 

y 5 

16 ^ It is believed that the enhanced electronic mail software 

1 7 disclosed in my previously incorporated parent application may be 

1 8 even further enhanced to provide more functionality regarding the 

19 use of "roles" in the contexts of electronic commerce, healthcare, 

20 business, and law, as well as in education. 
21 

22 Recently, the email client OUTLOOK by MICROSOFT has received 

23 much attention because of its ability to execute Visual Basic 

24 Scripts (VBS) attached to or embedded in the body of an email 
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1 message. While this ability has the potential of achieving some 

2 of the goals of the present invention, it has one major 

3 disadvantage. The recent interest in MICROSOFT OUTLOOK and VBS 

4 was spurred by the outbreak of several extremely damaging 

5 "viruses" or "worms". These Visual Basic Scripts attached to 

6 email destroyed files on the email recipient's hard drive and 

7 spread by sending copies to all of the email addresses in the 

8 recipients' address books. At the present time, the only sure way 

9 to prevent damage by malicious Visual Basic Scripts is to alter 



"^0 the "preferences" of OUTLOOK so that the ability to execute Visual 

1 Basic Scripts is disabled. 

: :; ; 

s1 3 SUMMARY OF THE INVENTION 

Q 

014 

^5 It is therefore an object of the invention to provide an 

y 6 electronic mail program which includes integrated 

1 7 authoring /reading software whereby different kinds of documents 

18 may be created, sent, received, and opened by electronic mail in a 

19 seamless manner, 
20 

21 It is another object of the invention to provide an 

22 electronic mail program which includes modular integrated 

23 authoring /reading software whereby different kinds of documents 

24 may be created and sent by email in a seamless manner. 
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1 It is a further object of the invention to provide an 

2 electronic mail program which includes modular integrated 

3 authoring /reading software wherein the functionality of the 

4 authoring /reading software is controlled by the "role" of the user 

5 when participating in an exchange of messages. 
6 

7 It is an additional object of the invention to provide an 

O 8 electronic mail program which includes modular integrated 

yi 9 authoring/reading software whereby the role of the user includes 

^0 such roles as customer, vendor, database, service provider, 

pj 1 technical support, teacher, student, attorney, client, doctor, 

^2 patient, and organization members having different security 

y 3 clearances . 
Jjl4 

Ql 5 It is another object of the invention to provide an 

1 6 electronic mail program whereby the role of the message recipient 

17 is automatically generated by the authoring/ reading component and 

18 encoded in the outgoing message. 
19 

20 Itisstill another object of the invention to provide an 

21 electronic mail program which includes installable 

22 authoring/ reading components which communicate with the email 

23 program through a bidirectional application programming interface 

24 (API). 
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1 In accord with these objects which will be discussed in 

2 detail below, the electronic mail software according to one 

3 embodiment of the present invention includes a main email 

4 component and a number of installable components which communicate 

5 bidirectionally with the email component through an application 

6 programming interface (API) . The installable components include 

7 authoring/ reading components as well as at least one mailbox 

8 browser/ editor component. The main email component provides an 

9 underlying graphical user interface (GUI) for functions directly 
yi 0 associated with the storage and transfer of electronic mail 

^1 messages. In particular, the main email component provides menu 

fy| 2 items which allow the user to SEND, READ, REPLY, FORWARD, DELETE, 

m 

SAVE, and PRINT, for example. The main email program also handles 

O 

iJH 4 all data 'bundling and unbundling that may be required to transform 

\j\ 5 a message created by an authoring component into a fully MIME 

o 

p1 6 compliant message. In addition, the main email component includes 

17 "hooks" (an application programming interface or API) for the 

18 attachment of the installable components. The authoring/ reading 

1 9 components each provide functionality which is particular to the 

20 type of document the component is designed to create/display. 
21 

22 According to the invention, some modular components have 

2 3 assigned "roles" whereby senders and recipients of certain email 

24 documents are provided different kinds of access to the documents. 
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1 For example, in the case of customer /vendor components, the vendor 

2 component allows a vendor to create an order form which appears in 

3 an email message read by the customer. The customer component 

4 allows the customer to fill in the form and mail back the filled- 

5 in data to the vendor or the vendor's database. A database 

6 component ..automatically reads the order data from the customer 

7 email and transfers this data to billing and fulfillment software. 
;:=^8 Other modular components having assigned roles include 

bidder/auctioneer, doctor /patient, attorney/client, etc. 

|o 

^1 The authoring/ reading components interface with the main 

92 email component via designated "MIME types". The MIME data 

0 3 standard allows developers to define MIME types using the label 

w = 

rt4 "x-"<string> in the data header where <string> is any ASCII string 

t^5 excluding space, control characters and other special characters. 

T 6 The MIME data standard also allows developers to define MIME 

1 7 subtypes using an extension to the label that appends the 

18 character "/" and a string to the MIME type. For example a Kidcode 

1 9 Rebus message might be identified with the content-type header set 

20 as "Content -Type: x-KidCode/Rebus" . Further, the MIME standard 

2 1 allows developers to include parameters within the contents of the 

22 ''Content -Type" header field. For example, the KidCode Rebus 

23 message might be associated with a particular feature such as the 

24 school grade level associated with this type of Rebus message, 
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1 e.g. "Content-Type: x-KidCode/Rebus grade = 1". The authoring 

2 components of the invention pass data to the main email component 

3 which packages the data as a MIME compliant message with the label 

4 "x-"<application> in the message header, where <application> 

5 identifies the authoring/reading component which created or can 

6 display the message. When the message is received, the main email 

7 component concatenates and decodes the MIME message, reads the 

8 MIME type, sends the data to the component associated with the 
Q9 MIME type, and waits for a user event or a callback from the 
rJIO component. This bidirectional communication between the main 
J[ 1 email component and the authoring /reading components provides a 
^2 totally seamless operation wherein the user may send and receive 
f1 3 complex documents without any knowledge of attaching files, 

^4 downloading, decoding, etc. Moreover, enhanced functionality is 

^^5 achieved through installable components. Only after the 

M6 appropriate component has been installed can an "active" email 

17 message call upon the component to execute. 

18 

19 Additional objects and advantages of the invention will 

20 become apparent to those skilled in the art upon reference to the 

21 detailed description taken in conjunction with the provided 

22 figures. 
23 

24 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 

3 Figure 1 is a very high level schematic diagram of the 

4 architecture of the email software of the invention; 
5 

6 Figure 2 is a somewhat lower level schematic diagram of the 

7 architecture of the email software of the invention; 

ft 9 Figure 3 is a screen shot of an email message created with a 

y 0 vendor authoring component and displayed by a generic 

+1 1 authoring /reading component which can control the generation of 
new messages for other authoring/reading components; 

03 



<yl 4 Figure 4 is a screen shot of an uncompleted email message 

-a 

q1 5 template generated by a customer reading /authoring component in 

16 response to the email message shown in Figure 3; 
17 

1 8 Figure 5 is a screen shot of the completed template of 
1 9 Figure 4 ; 

20 

21 Figure 6 is a screen shot of an interactive template created 

22 by an auctioneer authoring component and displayed by a 

2 3 bidder/seller authoring /reading component displayed in the bidder 
24 role; 
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1 Figure 6a is a screen shot of an interactive template created 

2 by an auctioneer authoring component and displayed by a 

3 bidder/seller authoring/ reading component displayed in the seller 

4 role; 
5 

6 Figure 7 is a screen shot of a doctor reading /authoring 

7 component ; 

\^ 

9 Figure 8 is a screen shot of a patient reading/authoring 

iji 

' 01 0 component ; 

Oil 2 Figure 9 is a state diagram illustrating how roles are 

p1 3 automatically assigned; and 

ii4 

SI 

x^l 5 Figure 10 is a state diagram illustrating the changes in role 

^6 in an authoring/ reading component. 
17 

1 8 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

19 

20 An exemplary embodiment of the architecture of the invention 

21 is described as follows with reference to an email client which 

22 will be distributed under the brand name UMBANET. Referring now 

2 3 to Figure 1, the email client includes a main client 10, having a 
24 main client API 12/ and one or more authoring /reading components 
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14, each having a component API 16. As described in the 
previously incorporated parent applications, the authoring/reading 
components each include a message handler 18 having an API and 
preferably an installable mailbox handler 20 having an API. 
Moreover, as described below with reference to Figure 2, 
installable components may be made up of either message handlers, 
mailbox handlers, or both. 

Referring now to Figure 2, the main email client 10 includes 
functionality for message transport 22, message encoding/decoding 
24, message storage and retrieval 26, basic GUI to mail services 
28, user administration 30, component installation 32, and special 
services 34. As mentioned above, the main email client 10 also 
includes an API 12 for communicating with authoring /reading 
components 14a, 14b, 14c, each of which have an API 16a, 16b, 16c 
for communicating with the main email client 10. In addition, as 
mentioned above, a* separate installable mailbox browser /editor 14d 
may be provided, having its own API 16d for communication with the 
API 12 of the main email client 10. An example of a specialized 
mailbox browser/editor component is disclosed in previously 
incorporated parent application [BAK-006] . 

The main email client 10 performs all of the usual functions 
of an electronic mail client. These include message transport, 
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1 message storage and retrieval, message encoding and decoding, user 

2 administration (including user preferences) . In addition, the 

3 main email client includes unique functionality required to enable 

4 installable components and special server -based services. 
5 

6 The message transport functionality 22 of the main email 

7 client 10 handles all functions traditionally associated with 

8 sending (SMTP) and receiving (POP, IMAP) email messages. This 

9 includes finding and verifying network addresses, and sending and 
yi 0 receiving mail messages to other servers on a network, 

=fcl 1 

Wl 2 The main email client 10 handles all data bundling and 

01 3 unbundling that may be required to transform the message data used 

fyl 4 by a message authoring component into a fully MIME compliant 

n15 message type via the message encoding/decoding module 24. This 

"^16 way each message authoring component handles data in a format most 

1 7 convenient to it and all MIME parsing and details associated with 

18 protocol compliance are centralized in the main email client 10. 

1 9 The only requirement for the message data passed between a message 

20 authoring /reading component and the main email client is that the 

21 message body data be formatted either as an ASCII string or in a 

22 binhex format. 
23 
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1 The main mail client 10 maintains its user mailbox files 

2 locally. The storage and retrieval module 26 implements all 

3 functionality required for reading and writing messages and 

4 mailboxes to/from permanent storage. 
5 

6 The .main email client 10 also includes a GUI 28 for user 

7 control of those functions that are directly associated with 

8 storage, display, and transfer of electronic mail messages and 

O 

^0 9 mailboxes. In particular, the main email client interface 

□1 0 includes buttons and/or menu items that allow a user to send a 

,^1 1 message, reply to a message, open a message or a mailbox, 

g1 2 delete/trash messages or mailboxes, save a message to an 

q1 3 alternative mailbox, and print a message. According to the 

4 presently preferred embodiment, the main email client user 

1 y 

^^215 interface operates simultaneously with the user interface of an 
authoring/reading component in the sense that both are active on 

17 the screen at the same time and present the "look and feel" of a 

1 8 single application. For example. Figures 6-8 show authoring 

1 9 reading components for an auction bidder, a doctor, and a patient 

20 respectively. As will be explained in more detail below with 

21 reference to Figures 6-8, each of the authoring/ reading components 

22 has its own interface which permits the user to interact with the 

23 component in a manner particular to the component. As seen in 

24 Figures 6-8 the authoring/reading component interface is generally 
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1 provided in a separate menubar or integrated within the space of a 

2 window. Nevertheless, the main mail client interface is still 

3 provided, for example at the main menubar where the File, Edit, 

4 Message, Transfer.., functions are always accessible. When a user 

5 interacts with the authoring /reading component interface, the 

6 authoring/ reading component handles the user event. However, when 

7 a user selects a function from the main email client, the main 
O 8 email client intercepts and handles the event. Generally, if a 
Ul 9 message handler component is open, a user event in the main 

f 1 0 program will require an API call to the message handler component 

nil 1 in order to fully execute the user invoked action. If, for 

s 1 2 example, the user selects the "send" function, the main program 

13 

fn1 3 intercepts the send request and makes a call to the API function 

■^1 4 msh_sendMessage (described in more detail below) in the active 

5 message handing component. The msh_sendMessage fxanction passes a 

16 valid message body back to the main program or, if for example, a 

1 7 valid message body has not yet been defined, passes a FAIL code 

1 8 back tO' the main program. 

1 9 

2 0 The user administration module 30 provides functionality for 

21 management of user information such as the user's POP mail 

22 account, SNMP server, etc. In the case of a multi-user mail 

23 client (e.g. the KIDCODE® client described in previously 

24 incorporated serial number 09/209,162), the user administration 
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1 module includes administrative functions and a user interface to 

2 add and modify information for more than one user. The module 

3 maintains a data structure consisting of all relevant user 

4 information for each user in the system. The module also manages 

5 files that are required for permanent storage of user infoirmation, 

6 if necessary. 
7 

8 The component installer module 32 handles the installation of 

Q 

ly 9 installable components (authoring/reading, mailbox, etc.) and 

^ 0 maintains a data structure of component information for each 

as 

^1 1 installable component. When a new message handling component is 

i 

installed into the mail client, the following information is made 

I J 3 accessible to the main mail client via the component installer: 

^!l4 MIME type of message handled by the component, component name and 

ly 

jfl 5 type, location and file name of program executable code for the 

O 

01 6 component, location (s) of icon image data for the component, and 

1 7 description of the resources that need to be installed into the 

18 main client, e.g. buttons, menu items etc. 



21 upon the programming environment within which the system is built 

22 and meant to operate. In order for installable components to 

23 operate properly, it is necessary for the main client program to 

24 be able to execute the new component's program code and make 



19 



20 



The implementation of the component installer is dependent 
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1 function calls to that code. It is not sufficient to execute the 

2 code as a completely separate program module because function 

3 calls and data must be passed between the main program and the 

4 component. For example, in a Windows environment, an installable 

5 component might be made up of one or more DLL's (dynamic link 

6 libraries) and one or more resource or ini files. The email 

7 clients described in the previously incorporated parent 

8 applications were implemented with MACROMEDIA DIRECTOR using 
sQ 9 protected movies and an MIAW (movie in a window) invocation 
Ql 0 architecture. A Java implementation would use loadable Java 
±11 classes to implement installable components. 

gl2 

,L1 3 The component installer should also be capable of editing 

fee 

^';1 4 data structures in the main program that manage the display of 

^15 relevant user interface controls. For example, the component 

□1 6 installer for the KIDCODE® client (described in previously 

17 incorporated serial number 09/209,162) adds a new button with the 

1 8 component icon to the main screen as well as making an icon 

19 available to the mailbox display component. It is also generally 

20 desirable to add entries for the new component to menus in the 

21 main client program. 
22 

23 An important part of the design of the component installer is 

24 a specification document that describes the format and type of 
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1 information that must be provided by each installable component in 

2 order to have that information installed into the main client 

3 program . 
4 

5 The special services module 34 allows the UMBANET mail client 

6 to communicate with UMBANET servers on the Internet in order to 

7 provide specialized services such as component downloads, message 
Q 8 tracking and accounting, recipient mail capability verification, 
m 9 PKI security and certification, etc. The UMBANET client uses 

^1 0 TCP/IP and a proprietary protocol to communicate with UMBANET 

311 1 servers. Once a TCP/IP connection has been established with an 

^12 UMBANET server, the client registers with the server. Thereafter, 

^1 3 the client and server exchange information using the UMBANET 

ISl 

^^14 protocol'. 

^ i 

015 

16 As mentioned above, the mailbox and the authoring/ reading 

17 components are preferably "installable". However, it is possible 

18 to create an email client having most of the desired functionality 

19 of the invention with fixed components hard coded. In either 

20 case, the invention prescribes that mailbox components are used to 

21 display, edit, and browse mailboxes. Different kinds of users and 

22 different types of messaging applications (e.g. fax, traditional 

23 email, internet voice) may require very different displays and 

24 functionality from a traditional mailbox viewer /editor . 
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1 Installable mailbox components make it possible to upgrade, select 

2 from multiple viewing formats, utilize different mailbox 

3 viewer /editors for different users, and in general increase the 

4 range of functionality that can be achieved within one basic 

5 messaging application program. 
6 

7 The message authoring/display (message handler) components 

8 make it possible to handle an unlimited number of message types. 

^0 9 Each message handler component is designed to deal with a specific 

□10 MIME type of message. The MIME data standard has been designed so 

^ 1 that application developers can define new MIME types as needed by 

E ^ 

Q3I 2 labeling these with the "x-"<string> prefix. A message handler 

fn1 3 component can be any program that defines a message MIME type of 

4 data that it handles, implements the callback API functions 

^ 5 described below, and matches the requirements imposed by the 

u 

6 component installer module. API callback functions allow the main 

1 7 email client to obtain information about the message handlers and 

1 8 allow the message handlers to respond to standard mail commands 

1 9 such as Send or Reply, that have been issued by a user through the 

20 main email interface. 
21 

22 As described in more detail below with reference to Figures 

23 3-8, some of the types of message handler components contemplated 

24 by the present invention are those which can be thought of as 
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1 creating "roles" among senders and recipients of mail messages. 

2 As will be further elaborated, either the message handler or the 

3 message created by it can establish the "roles" of the recipients 

4 and the authors such that recipients and authors are each 

5 permitted to interact with the message in certain different 

6 predefined ways. 
7 

^ 8 Before describing the specific message handlers of the 

9 instant invention, it is useful to first fully describe the 

^ 0 preferred APIs used to implement the main email component, the 

^4 1 mailbox components, and the message handlers. 

m 

ffl 3 Main Email API Functions 

y 4 These functions are called by the installable components to 

Hi 5 access services provided in the main email program. 
16 

1 7 exiih_getUserMailbox (dt_MailBoxName) 

1 8 This returns a mailbox data structure for the current user 

19 and mailbox name. This function is normally called by a mailbox 

20 handling component. Mailbox handling components may use temporary 

21 files to hold mailbox contents but they preferably never access 

22 the users mailbox files. All access to these files should be 

23 obtained through the main email program. The input to this 

24 function is (dt_MailBoxName) and the output is dt_MailboxData. 
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1 einh_getUserData ( dt_UserNaine ) 

2 This returns a data structure with user information (in a 

3 multi-user client) . The main email program maintains all user 

4 information and handles user administration functions. The main 

5 program also communicates with external mail servers which may 

6 contain ether user information. The input to this function is 

7 (dt_UserName) and the output is dt_UserData. 
8 

Q 

9 exnh continue 

qiO This function is used by installable components to explicitly 

pass control back to the main email program. This function is 

1 2 necessary for the present implementation which uses MACROMEDIA 

13 DIRECTOR LINGO code. It is not a requirement for alternative 

14 implementations. The function has the argument 

15 (dt_ComponentType) . 
016 

1 7 einh_k ill Component 

1 8 This function is used by an installable component to inform 

19 the main email program that it is preparing to terminate. This 

20 allows the main program to free any memory and/or data structures 

21 that have been allocated to the component. 
22 

23 
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1 enih_pas sMes sage 

2 This function is used primarily by mailbox components to pass 

3 a message to the main program so that it can be displayed by the 

4 appropriate message handling component. The main program takes 

5 the message arguments (em_MailData) or (em_MessageAction) . The 

6 former looks up the Mimetype of the message, and invokes the 

7 appropriate message handler to display the message. The latter is 

8 used with #open, #print, #send, ...etc . 
f 9 

M 0 emh^getMessage 

^1 1 This function returns the message (em_MailData) with Number 

1312 MessageNumber from the MailboxName of the current user. It can be 

Q1 3 used by installable components to retrieve specific messages from 

ml 4 the user's mailboxes. If this is called with the messageNumber 

□15 set to 0, the main email assumes the typeOrBoxName argument is a 

O 

*^1 6 mimetype and returns a new message structure. Message handling 

1 7 components should call emh_getMessage with the number set to 0 and 

1 8 the mimetype whenever a new message is started. Normally this 

1 9 should be done whenever an active message is trashed. 
20 
21 
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1 einh_getRegisteredUsers 

2 This returns a list of usernames (dt_RegisteredUsers) for the 

3 users that are registered with the email client, i.e. that have 

4 been added as users by the user administration part of the main 

5 email program. This is the same list of users that appears in the 

6 logon listbox when the program is started up. It may be used by 

7 installable components to create listboxes for filling address 

8 fields in messages or for checking whether a particular address is 
^g9 external to the system. This function may be used with an 

QO argument that specifies a MIME type. When so used, the function 

"A 1 will return a list of users who are authorized to receive (or 

rt 3 

2 capable of displaying) messages of the specified MIME type. The 

^ 3 indications of the authorizations or capabilities of users may be 

yi 4 stored on a local server, on a remote server (via the Internet), 
or may be stored locally on a user's computer. 

016 

1 7 emh.sendMessage 

1 8 The main email client sends a message with the argument 

1 9 (em_MailData) by either forwarding it to an external mail server 

2 0 or, if it is a registered email client user, writing the message 
21 to the user's incoming mail mailbox. 

22 
23 
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1 emh.saveMessage 

2 The main email client saves a message with the argiiment 

3 {em_MailData) for the currently logged on user by writing the 

4 message to the user's "notes in progress" mail mailbox. 
5 

6 eiQh_disableButtoxi 

7 It is recommended that this function be used carefully. 

8 Normally, the main email program controls the state of all the 

kg 9 buttons available to users to access message handling of the main 

gi 0 program. This function can be used to request that the main email 

Jl 1 program disable the button specified by the argument, ButtonName. 

nj 

li^^2 If the button is disabled, whether it was already disabled or is 

^.13 disabled as a result of this function call, this function will 

^:14 return TRUE, otherwise it will return FALSE. The calling 

5 component should check whether the function call succeeded and 
Q16 proceed accordingly. The ButtonNames are #reply, #send, #print, 

1 7 #trash, etc . 
18 

1 9 emh.enaQ^leButton 

20 It is recommended that this function be used carefully. 

21 Normally, the main email program controls the state of all the 

22 buttons available to users to access message handling of the main 

23 program. This function can be used to request that the main email 
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1 program enable the button specified by the arg\ainent, ButtonName. 

2 If the button is enabled, whether it was already disabled or is 

3 disabled as a result of THIS function call, this function will 

4 return TRUE, otherwise it will return FALSE. The calling component 

5 should check whether the function call succeeded and proceed 

6 accordingly. 
7 

|3 8 API Functions For Use With All Component Types 

m 9 

.. o 

£l 0 emc.startMeUp 

fy1 1 This function is used by the main email program to tell an 

^"12 installable component to start. This function will execute prior 

Q 

S1 3 to initialization of the component's data structures, which should 

w - 

nj 

4 only be initialized after the component receives the 

yi 5 emc_initWindow call from the main email program. This function is 

1 6 necessary for the MACROMEDIA DIRECTOR LINGO code implementation 

1 7 and may not be needed for other implementations . 
18 

1 9 einc_initWindow 

20 This function is used by the main email program to tell an 

21 installable component to initialize its data structures and 

22 prepare its graphical display. The component is passed the 

23 username of the current user. If the component requires 
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1 additional user information in order to initialize, it can call 

2 einh_getUserInfo within its implementation of this function. 
3 

4 einc_closeWindov7 

5 This function is used by the main email program to tell an 

6 installable component to free all memory that it has used, close 

7 its window, and shut down. 
8 

,g 9 emc_getConiponentInfo 

0 This function is used by the main email program to get 

J1 1 required infomation such as componentName, componentID, etc. from 

1^12 an installable component. This function should not be called 

^13 until the component window is fully open. 
0114 

5 API Functions For Use With Mailbox Handler Components 
016 

1 7 xnbx_getMessageNuinbers 

1 8 This function is used by the main email program to get the 

1 9 message number of the currently selected message in the mailbox 

20 browser. If no message is selected, the list should be empty. 
21 

2 2 inbx getMessage 

23 This function is used by the main email program to get the 

24 message data structure of the message with em__MessageNumber from 
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1 the mailbox currently displayed in the mailbox browser. If the 

2 function fails, e,g, if there is no message with the given message 

3 number, the function returns an empty list. 
4 

5 iabx_trashMessages 

6 This -function is used by the main email program to tell the 

7 mailbox component that it has received a trash event (e.g. user 
Q 8 pressed trash button) . The component should identify which 

9 messages have been indicated by the user and return these messages 

- 

2 0 in a list data structure. If no messages have been indicated by 

4I 1 the user or if the component wishes to cancel the operation it 

i H 3 

^^4 2 should return an empty list. When it receives this call, normally 

Q 3 the mailbox component will update its display and its data 

fU 4 structures to delete messages that have been indicated by the 

01 5 user. 
16 

1 7 xnbx_openMailbox 

1 8 This function is used by the main email program to tell the 
1 9 mailbox component to display the mailbox passed in the argiament 
20 (dt_Mailbox) . 

21 
22 
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1 Functions For Use With Message Handler Components 



2 



3 msh_sendMessage 



4 



This function is used by the main email program to tell a 



5 message handling component to pass back a fully completed message 

6 data structure so that it can be sent to the recipient specified 

7 in the message's address field. The message handling component 

8 should update its display as appropriate for a message that has 
^'9 been sent. It should also change its state to display mode 



2 message cannot be constructed (for example, if the user has not 
^13 specified a message recipient), the function returns an empty 



17 dialogs with a user that pertain to a message under construction. 

1 8 For example, to alert the user that a message recipient must be 

1 9 specified. However, if the message handling component fails to 

2 0 pass back a properly formatted, completed message data structure, 

21 (or an empty list acknowledging failure), the main email program 

22 will detect the error and alert the user about the field or fields 

23 that have not been specified. 




pf 0 because a message that has already been sent should not be 
fll editable. If the function fails, e.g. if a fully completed 




The message handling component will normally control all 



24 
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1 msh.opexiMessage 

2 This function is used by the main email program to pass a 

3 message data structure to a message handling component so that it 

4 can be displayed. The message handling component should display 

5 the message in the specified mode (e.g. either #author or 

6 #di splay).-. If the em_Mode argument is #di splay the message should 

7 not be editable. Otherwise the message should be opened so that 

8 it can be edited. If the function fails, e.g. if an error is 

^ 9 detected in the message body, the message handler returns FALSE, 

^^10 otherwise the message handler returns TRUE. 

f^ 1 

Ml 2 xQsh_replyMessage 

01 3 This message is used by the main email program to inform a 

fdl 4 message handling component to display the currently active message 

q15 for editing as a reply. In order to reply, the message handing 

b 

1 6 component will generally create a new message with the mode set to 

17 #author. If the function fails, e.g. if an error is detected in 

1 8 the message body, the message handler returns FALSE, otherwise the 

1 9 message handler returns the messageBody which may have been 

20 modified. 
21 

22 
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1 msh_c 1 earMe s s age 

2 This function is used by the main email program to inform a 

3 message handling component that the current message should be 

4 cleared from the display and from the message handling component's 

5 data structures. This function is used, for example, when the 

6 user indicates they want to trash the current message by clicking 

7 on the ''trash" button in the main email program GUI. If the 

8 fxinction fails, the message handler returns FALSE. Otherwise the 
Jg 9 message handler returns TRUE. 

gio 

=P1 1 xash_saveMessage 

2 This function is invoked when the main email program receives 

p1 3 a save event, e.g. the user presses the "Save" button. The 

fy14 message handler should pass the messageBody back to the main email 

q15 program to be saved. In general, the message handler should 

'""16 maintain its state when this function is called because the user 

17 may want to continue editing the message. 

18 

1 9 msh_printMessage 

20 This function is used by the main email program to inform a 

21 message handling component that a message should be printed. This 

22 function is used, for example, when the user indicates they want 

23 to print the current message by clicking on the "print" button in 

24 the main email program GUI. When the argument, em_mailData, is an 
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1 empty list, the message handler component should print the 

2 currently active message. Otherwise the message handler component 

3 should print the message argument. Normally, if the message 

4 handler component has been fully initialized and is displayed in a 

5 window, the main email program will call this function with an 

6 empty list' for an argument. The function may also be used by the 

7 main email program to have a message handler print a message even 
C8 though the message handler component has not been fully 

09 initialized and displayed in a window. For example, this will 

Jt 0 occur if an active mailbox component receives a print request from 

1 the main email program for a message that has been selected in the 

2 mailbox browser. In this case, the main email program will send a 
si 3 request to the appropriate message handler component to print the 
-3 4 message without fully starting it up and initializing its window. 
M 5 Therefore the message handler should implement the 

16 msh_printMessage function so that the following ' sequence of 

17 function calls succeeds emc_startMeUp, msh_printMessage (message) . 

18 If the function fails, the message handler returns FALSE. 

19 Otherwise the message handler returns TRUE. 
20 

2 1 msh_trashMessage 

22 This function is used by the main email program to tell a 

23 message handler component that it has received a trash event (e.g. 

24 user pressed trash button) . The component should do whatever is 
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appropriate and return its currently open message data structure. 
A component may want to display a dialog box to verify the trash 
operation before proceeding, (e.g. emh_alertUserToTrash) If the 
component wishes to cancel the operation, it should return an 
empty list. Normally a message handling component will update its 
display and its data structures to clear the trashed message from 
its display. 

From the foregoing, those skilled in the art will appreciate 
that message handling components may be created for different user 
roles and/or messages may be assigned certain role information 
which controls how the recipient (s) of the message interacts with 
the message. Moreover, certain message handling components can 
provide different levels of authoring and different levels of 
readership based on "roles." 

Turning now to Figures 3-5, one implementation of a message 
handling component is that of a "customer" component (or a 
reading/authoring component which is responsive to a "customer 
message role) . Figure 3 illustrates an email message 40 which was 
created by a "vendor" component (or an authoring/reading component 
in a "vendor" role) . Figure 3 shows the message as it appears on 
the recipient's computer screen. As shown the message appears to 
be a simple plain text email message with a hot link 42 to the 
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1 vendor's web page (the underlined sentence "Click here to Go to 

2 Our Web Page for more Details."). However, the second hot link 44 

3 in this message (the sentence "Click here to Automatically Order 

4 the Product by Email") invokes special functionality of the 

5 reading/authoring component installed in the recipient's email 

6 program. 'When the user clicks on this second hotlink, the 

7 "customer" message handling component causes a new outgoing email 

8 message 46 to be created as shown in Figure 4. 

^0 As shown in Figure 4, the new mail message is pre-addressed 

£l 1 and the body contains information relating to the order which will 

J^i 2 be placed when the new message is sent. The body of the message 

,L^1 3 is actually a template which was created from information 

!!rl 4 contained (though hidden from display) in the email message 40 

^15 received from the vendor. This information was not displayed in 

□16 the original message shown in Figure 3, but was made known to the 

1 7 message handling component for use in creating the template 45 

1 8 shown in Figure 4 if the user clicked on the second hot link 44 in 

1 9 Figure 3 . The customer role assigned to this outgoing email 

20 message 46 allows the user to make only limited additions to this 

21 template. Specifically, the user may enter a nximber of items in 
2 2 the blank 48 and a choose a size using the "radio buttons" 50, 

23 then click on the send mail icon 52. This template is interactive 

24 and controlled by the message handling component so that as soon 
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1 as the user selects a number to order, the purchase price is 

2 displayed in the field 54 as shown in Figure 5. In order to 

3 minimize the amount of input required of the customer, the 

4 purchase price is preferably charged to an account already set-up 

5 with the vendor. This mode of operation also maximizes the 

6 security of the transaction. 
7 

8 As mentioned above, the user can click on the send mail icon 

m 

JLJ 9 52 once the form is filled in. Preferably, the send mail icon 52 

0 will remain "grayed out" until the user completes all of the 

^ 1 information required by the form. If the user changes his/her 

M 2 mind about placing the order, s/he may simply close this window 

(1113 without sending the message. If the user clicks on the send icon 

Ki\ 4 52", the mail is sent back to the vendor, preferable with an 

qI 5 assigned role of "order fulfillment", for example. The message 

1 6 may also be preferably addressed to an automatic mail handler 

1 7 which will automatically extract information from the order and 

1 8 from the customer database and process the order. 
19 

2 0 Figure 3 shows what looks like a standard HTML message but is 
2 1 used to open a customer reading /authoring component displayed in 
22 Figures 4 and 5. The screen shot of Figure 3 doesn't show what 

2 3 the vendor authoring component would look like since it is 

24 displayed from the point of view of the customer. On the other 
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1 hand, the message can be used to start a new message in the 

2 "customer" component. There are different scenarios that could be 

3 depicted by Figures 3-5. 
4 

5 According to the first scenario. Figure 3 shows a message 

6 displayed In a customer component with the "customer" role. The 

7 customer clicks on the "Click here to Automatically order..., " and 
08 the customer component starts a new message that is assigned the 

yl9 role "vendor" (i.e. it will be received by a participant in the 

■ O 

iiO vendor role) . The new message with the "vendor" role is displayed 

f§1 in the customer component is shown in Figure 4. This is an 

fri 

jf2 interpretation that matches closely to the operation of the code 

!3 3 included in the parent application. However, in the original 

y 3 

4 code, the invocation of the new message is normally done by 

3 5 hitting the "reply" button in the main interface rather than a 

O 

16 field displayed on the incoming message. 
17 

18 This functionality is useful if it is necessary for a message 

19 author (e.g. a vendor) to control the assignment of role 

20 information associated with various types of replies on an 

21 individualized basis. For example, if it wanted certain types of 

22 customers to have access to the online customer service and wanted 
2 3 to encode this in the message body itself. In this case, some 

24 customers would receive a message looking similar to the one 
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1 displayed in Figure 3 with an additional line that says "Click 

2 here to request customer support" in which case a new message with 

3 a role assigned to be "Saleslnfo" would be created in the Sales 

4 authoring /reading component. 
5 

6 According to the second scenario Figure 3 shows a message 

7 displayed in a "controller" component that is capable of 

8 responding to an input pair (message data + user action) by 
opening new messages in other components. When the customer 

^0 clicks on the "Click here to automatically order..," the 

~p1 1 "controller" component opens a new message in author mode (perhaps 

Hi : 

Jij 2 tagged with the "customer" role) in the "customer" component. 

y 3 This scenario could be implemented by sending an HTML- like message 

Jfl 4 with a message MIME type set up to identify the controller 

I E ? 

Nil 5 component, e.g. "x-ControllerMsg" whose body consists of a set of 

o 

131 6 data pairs (display_string/associated component to open/ data 

1 7 parameters for component) . For example, the screen shown in 

1 8 Figure 3 could be generated by a message that had a "Content-Type 

19 = x-ControllerMsg" and a message body that consists of: 
20 

21 ("One Day SpeciaL../nil/nil) 

22 ("Click here to go to our Web Page for more details."/ text/HIML / 
2 3 "http: //www. sales . ccm" ) 
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1 ("Click Here to Autcsnatically Order t±iis Procauct ty Erail'V x-Sales/Custcmer 

2 /"PID 121121") 
3 

4 Existing mail clients are almost capable of implementing this sort 

5 of behavior using HTML and Javascripts, If an existing mail 

6 client were modified to be able to run Javascripts, the message 

7 displayed in Figure 3 could consist of HTML and Javascripts. When 

8 the user clicks on the "Click here to automatically...." A 

9 Javascript could run that opens the customer component with a new 
q1 0 message with the vendor role (as shown in Figure 4) . However, as 

1 mentioned above, this type of implementation would open the mail 

1^12 clinet user to malicious Javascripts. According to the preferred 

1^1 3 embodiment of the invention, no executable code is contained in a 

yj1 4 message, only tags which are read by the authoring/reading 

r Li 

""'"^l 5 component. 
01 6 . 

1 7 Figure 6 shows another similar example of a message handling 

18 component /role is used in e-commerce. Figure 6 shows an email 

1 9 message 60 which was generated by an "auctioneer" component (or an 

20 authoring/reading component in auctioneer mode) . Figure 6 shows 

21 the message as it appears on the computer screen of a "bidder". 

2 2 This message contains several graphic components 62, 64, three 

23 text message fields 66, 68, 70, and an input template 74. The 

24 message 60 is a combination incoming/outgoing template. The 
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1 bidder fills in the appropriate parts of the template 74 and 

2 clicks on the "reply" button 76. The bidder's authoring/reading 

3 component composes an appropriate message to the auctioneer and 

4 sends it automatically and transparently. The user will see the 

5 message 60 disappear and preferably see a dialog box or window 

6 notice saying "Message Sent" or the like. 
7 

Q 8 As mentioned throughout above, the concept of role may be 

ill 9 associated with a particular component or with a message created 

£1 0 by the component. In the auction example, it is desirable that 

m\ 1 the non-auctioneer component have at least two modes of operation, 

2 one being the role of bidder and the other being the role of 

;i1 3 seller. The bidder role is illustrated with reference to Figure 6 

4 described above. The seller role is illustrated with reference to 

^1 5 Figure 6a which shows a message template 61 which is created when 

16 the user chooses to post a for sale message. The template 61 

17 includes a title field 63, a category field 65, a description 

18 field 67 and an option checklist 69. 
19 

20 According to a presently preferred embodiment, the concept of 

21 role is associated with the message and authoring /reading 

22 components are capable of creating and reading messages having 

23 different roles. In the KidKode® embodiment of the invention, the 

24 role of the message is contained within the body of the message. 
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1 According to other embodiments, the role of the message is encoded 

2 in the MIME type, subtype, a parameter in the "Content_Type" 

3 header, or in the subject header. The processing of a message 

4 with a specified role may be carried out either by an 

5 authoring /reading component designed specifically to handle 

6 messages with the specified role or by an authoring /reading 

7 component that is built to handle all messages of a specified MIME 

8 type. When the authoring /reading component handles all messages 
iQ9 of a given MIME type it includes within it the logic necessary to 
So process messages with different roles differently. 

f 1 

^ s 

!3 2 As mentioned above, in the KidCode® embodiment, the message 

y 3 role is encoded in the message body and is handled entirely by the 

Its? 

4 authoring/reading components. This has advantages over an 

5 alternative that records the message role in a message header 
13 6 field because the mail email client can be independent of any 

1 7 knowledge of roles and does not need to be encumbered with role 

18 handling logic that is best left to component designers. However, 

1 9 this places a restriction on the design of authoring/reading 

20 components. If role information is embedded in the message body, 

21 it is not advisable to allow the creation of authoring/reading 

22 components specialized to handle certain roles. To do so would 
2 3 require that the main mail client software be capable of parsing 
24 the message body in order to find the role information and. 
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1 thereby invoke the proper authoring /reading component for a given 

2 message. Good software design principals require a strict 

3 separation between the data available to the main mail client and 

4 data that is processed exclusively by authoring/reading 

5 components. Maintaining this separation is very important to 

6 ensure integrity of the API which allows independent software 

7 developers to build authoring /reading components that can be 

8 guaranteed to work properly with a main email client program. 

QO Nevertheless, there are many types of transactions in which 

P 1 each participant in an email exchange acts in a single role. For 

si : 

J3 2 example, in the Doctor/ Patient application described below, the 

y 3 individual who is the patient normally does not take on the Doctor 

^14 role. In this case, it is both more secure and more efficient to 

^1 5 construct separate authoring/reading components to handle Doctor 

r ! 

Ol 6 or Patient messages. It is also desirable to recognize that these 

1 7 are two sides of the same transaction and encode all messages 

v18 associated with the transaction with the same MIME type. 
19 

20 A solution that enables both the development of 

21 authoring/reading components specialized to handle particular 

22 roles and guarantees data separation as* described above is to 
2 3 encode role information as a subtype of the MIME type in the 
24 "Content- type" header field. Using this method, the main email 
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1 client would properly invoke the correct authoring/ reading 

2 component in the case that an independent authoring/reading 

3 component has been constructed for handling a specified message 

4 role. Another alternative is to encode role information in the 

5 parameter that may be optionally included in the "Content- type" 

6 header as -defined by the MIME standard. In this case, the main 

7 email client maintains data separation with respect to the message 

8 body but is required to parse the Content-Type parameter. The 

^5 9 additional complexity necessary in the main mail client software 

Ql 0 causes this to be an inferior solution. 
^ 1 

g1 2 Figures 7 and 8 illustrate authoring /reading components 

3 having the roles of "doctor" and "patient". Figure 7 illustrates 

Sj1 4 a message template 80 for use by a doctor. The message template 

,^15 is divided into three main parts 82, 84, 86. The first part 82 

^"1 6 presents the doctor with pop up menus for selecting, for example, 

1 7 patient name, prescription number, test provider, test number, 

1 8 etc . Radio buttons are also used to enter inf oirmation about 

19 prescription refills, generic substitution, etc. The second part 

20 84 is a text editor window where the doctor may compose a personal 

21 message to the patient. The third part 86 is a text entry 

22 template HMO information, consultation charge, etc. After the 

23 doctor fills out the message template 80 and sends it, the 

24 authoring /reading component prepares a message to the patient and 
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1 a message to the HMO, Optionally, the authoring /reading component 

2 could also prepare messages to a pharmacy, to a test lab, etc. 
3 

4 Figure 8 illustrates the message 90 received by the patient 

5 as a result of the doctor filling in the template 80 (Figure 7) . 

6 The message 90 presents the role of patient and organizes 

7 information in a manner useful to the patient. The message 90 

8 includes a text field 92 which displays the text message composed 

9 by the doctor and entered into the text field 84 in Figure 7 and 
^10 several check box fields 94, 96, 98. Field 94 allows the patient 

1 to request information about a medical condition. Field 96 allows 

^^1 2 the patient to select certain parameters regarding the filling of 

ts 

^13 a prescription and to request a copy of diagnostic test results. 

O 

oi1 4 Field 98 allows the patient to purchase and obtain information 

Sis 

's|1 5 about vitamins. Figure 8 also illustrates a pop-up dialog box 100 

q1 6 which alerts that patient regarding to the billing information 

17 entered by the doctor in field 86 of Figure 7. When the patient 

1 8 selects parameters regarding the filling of a prescription, the 

1 9 patient component automatically sends emal to the pharmacy with 

20 only the information needed by the pharmacy to fill the 
2 1 prescription . 

22 

2 3 From the foregoing, those skilled in the art will appreciate 

24 that the concept of "roles" as implemented herein may be expanded 
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1 to a number of different useful applications of interactive email. 

2 The roles described and illustrated above include customer, 

3 vendor, database, doctor, and patient. Previously incorporated 

4 parent application serial number 09/209,162 disclosed several 

5 examples of teacher and student roles. Those skilled in the art 

6 will appreciate that the principles describe herein can be applied 

7 to roles such as service provider, technical support, attorney, 

8 client, and organization members having different security 

O 9 clearances. Service provider and technical support will present 

yl1 0 templates requesting information needed to diagnose a problem. 

::P1 1 Reply mail with data fill-in can be parsed by an artificially 

ft|1 2 intelligent mail reader and tentative diagnoses sent by email to a 

J"1 3 human representative. The attorney and client roles may be 

;^14 implemented in a manner similar to the doctor and patient roles. 

;jjl5 The roles of organization members have different security 

1 6 clearances can be implemented in a manner whereby a message 

1 7 created by someone with the highest security clearance is 

1 8 classified in different ways so that only those with the proper 

19 clearance can read it. For example, it is possible to create a 

20 message where some parts of the message are highly classified and 

21 other parts of the message are given lower classifications. 

22 Readers with high security clearance will be able to read all or 

23 most of the message. Readers with low clearance will only be able 

24 to read parts of the message. 
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1 As Stated above, normally the role information associated 

2 with each message is assigned to the message when it is created or 

3 when it is sent, A role can often be automatically assigned to a 

4 message by the authoring/reading component used to author the 

5 message. The role given to a message may be based on many 

6 factors including the state of a previous message (or sequence of 

7 messages), information selected by a message author, and 

8 information associated with the message recipient and/or the 

'•J 9 message author. In the KidKode® embodiment, the authoring/reading 

components built for children's educational games automatically 

=H 1 assign a role to a message on the basis of the state of a previous 

ry| 2 message. 

ffrt 4 Figure 9 shows the state diagram used to determine how roles 

m 

5 are automatically assigned to KidCode® messages. In a preferred 

q1 6 embodiment of the KidCode® coder /decoder games, when a user starts 

17 a new message at 110 by pressing the message authoring button in 

1 8 the main client program, the message is tagged as a "new" message 

19 and treated as a ''coder" message. When the message is sent, the 
2 0 message role is set to "decoder" at 112 because the message 

21 recipient will play the role of decoder of the puzzle. When the 

2 2 decoder sends the reply to the message the role of the outgoing 

2 3 message is set to ''coder" at ,114, When the coder participant 

24 receives that reply from the decoder, the fact that the message is 
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1 tagged with the "coder" role causes appropriate "cod.er" tools to 

2 be made available by the authoring component. As is shown in 

3 Figure 9, each time a reply message is created a copy of the 

4 original message is made and the message role is set to the 

5 opposite role. 
6 

7 Figure 10 elaborates on the manner in which messages are 

8 displayed by the KidCode® Rebus and Grid message handling 

''^ 9 components. Whereas Figure 9 describes transitions undergone by a 

^ 0 message (or message descendants) , Figure 10 shows the transitions 

Q 

=^ 1 of the state of an authoring/reading component. This Figure 

fyl 2 provides a more complete picture of how an authoring /reading 

5 1 3 component can use the message role and the message display mode, (a 

[pi 4 property of the authoring/reading component that normally takes 

fy 

5 one of the two values, "display" or "author") to determine how a 

JSI 6 message should be displayed and what tools are available to the 

17 message author or reader. On start 115, the component has three 

18 options. One option is to create a new message in the coder role 

19 (component author mode) 118. Another option is to open a message 

20 in the decoder role (component display mode) 120 in order to view 

21 a puzzle created by another. Still another option is to open a 

22 message in the coder role (component display mode) 122. This 

23 option would be used to view a response by a decoder to a coded 

24 message created by the current user. If the user chooses to reply 
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1 to this message, the message role is changed to decoder (component 

2 author mode) 124. 
3 

4 The above illustration illustrates an important distinction 

5 to note regarding the interaction of the message mode and the 

6 message role. For many types of interactions it is desirable to 

7 control the information that is seen by the user depending upon 

8 the role that the user has in a given transaction or series of 

^-^ 9 exchanges. For example, messages that have already been sent and 

y 0 reside in the outbox are read only messages (i.e. always opened 

=^1 1 with the mode set to "display") . In the case of an authoring 

riJl 2 component such as the KidCode® Rebus or Grid, in which the role of 

5 1 3 a sent message is in an incorrect state for the message author 

g]1 4 (i.e. a decoder's message that has been sent has the "coder" 

I ii 

5 role) , a "display" mode message must be viewed as having a 

n 

;Sn 6 different role than it actually carries. If a Rebus decoder were 

17 to see his reply message after it has been sent with a "coder" 

1 8 role, he would be able to view the answers to the puzzle in the 
1 9 messages in his outbox. The logic to handle the various 

2 0 interactions between message modes and message roles are included 

21 in' the authoring /reading component. In this way the main email 

22 component is separated from all aspects of message roles which are 
2 3 properly the domain of an particular messaging application. 

24 
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1 There have been described and illustrated herein several 

2 embodiments of electronic mail software with modular integrated 

3 authoring /reading software components including methods and 

4 apparatus for controlling the interactivity between mail authors 

5 and recipients. While particular embodiments of the invention 

6 have been- described, it is not intended that the invention be 

7 limited thereto, as it is intended that the invention be as broad 

8 in scope as the art will allow and that the specification be read 

9 . likewise. Thus, while particular APIs have been disclosed, it 
^"1 0 will be appreciated that other APIs could be utilized provided 
p1 1 that the basic functionality described herein is maintained. 

4=: 
f% 3 

2 Also, while "installable" components have been discussed in 
detail, it will be recognized that permanently installed 

Jj1 4 components could be used with similar results obtained, less the 

nj 

^'4^ 5 ability to upgrade functionality in an easy manner. Moreover, 

131 6 while particular configurations have been disclosed in reference 

17 to the relationship between the main email client, the message 

1 8 handlers, and the mailbox handlers, it will be appreciated that 

1 9 other configurations could be used as well provided that the basic 
2 0 functionality of the invention is maintained. It will therefore 

21 be" appreciated by those skilled in the art that yet other 

22 modifications could be made to the provided invention without 

23 deviating from its spirit and scope as so claimed. 
24 
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